Everybody loves Cloud Platform teams these days. They're especially prelevent in larger companies where you frequently find multiple development teams, and the company standards for security, avaialbility and audit are very high.
Note: In the modern world even small teams should have really high standards for security etc. (hackers are not known for taking symathy with smaller organisations - they just love to hack), but in my experience the ability to prove that you've run all the neccesary checks and procedures is significantly more costly and difficult that it might appear.
Anyway, the reasons why you might choose to have a Platform team probably desrve a seperate blog post. For now, I'll assume that you've decided to have one, and that a big focus of your team will be Infrastructure-As-Code. In fact if your Platform team isn't foccussed on Infrastructure-As-Code, you've just recreated and old school Infra team, and you'll be missing out on a huge amount of the benefits of working in the cloud.
So I've been lucky enough to help build Cloud Platform Teams as two major organisations in the last few years. Even better, both organistaions were at the start of thier cloud journey, so we had plenty of freedom to experiment with how we organised and executed our work. Because we were well experience in standard agile developer techniques, we naturally set about creating backlogs, sprints and all the usual Agile ceromonies. This post is about which ones worked and which ones didn't.
Another Note: The book "Team Topologies" has been very influential in this area, and I referred a lot to thier previous work on DevOps patterns and anti-patterns. If you haven't heard of them, start with thier website.
Daily Stand-Ups
I've yet to find a project where a daily stand-up doesn't help. Even if the team are well organised and great communicators, the ritual of a daily (strong preference for first thing in the morning) stand-up is a great way of getting everyone together and keeping focus. As a Platform team matures, and starts supporting more and more development teams, there will naturally be "issues of the day" that need addressing. The stand-up really helps with this. If some unplanned work has reared it's head, then it's a great place to communicate who is working on it, and get some quick input from the rest of the team.
Note: I have recently seen a number of posts criticising Daily Stand-Ups. It's clear that not everyone loves them. Personally I find that as long as the discipline to stick to a maximum of 15 minutes is observed, they're a great way of helping the team stay in touch. It can become complicated if remote teams are based in different time zones, but I'll default to persevering with this tactic. I often find that Fridays stand-up is dominated by discussions about the weekend plans for the team. I see this as a real positive! It's a good sign that the team trust each other and are treating each other as group of people with feelings.
Problems with Sprints
We initially attempted to follow a standard a standard Scrum process with Sprint planning, sprint reviews and retros. This wasn't particularly succesful for a number of reasons:
- It's always hard to estimate, but it's really hard at the start of a project, when everythings new and there's very little repeat activity
- A large percentage of our initial tasks had external dependancies (e.g. waiting for coporate fireall changes), and these frequently hampered our ability to finish them before the end of the sprint and meet our comitments.
- User feedback arrived immediately, as users of the new platform experimented with the new cloud technology. This meant we had pressing service requests to deal with very early in the project.
The issues with trying to adopt a sprint methodology became clear to me when I saw the team struggle to plan a sprint containing a huge variety of tasks. Onboarding teams to the new platform (medium), urgent changes for onboarded teams (small but plentiful) and major new plaform features (large and unpredictable). One of the features of Sprints is the sense of satisfaction for a team when completing a Story or Work Item on time. We wwre experiencing the opposite effect. Failing to meet our Sprint objectives was demoralising for the team, and for a while we wasted time try to break down stories in attempt to find a way of delivering promises to stakeholders. I swiftly realised that this was creating worthless additional work. We were spending too much time trying to make the Sprint process work, when we should have been foccussed on simply shipping value to our users.
At the start of the project we had a made a comitment to doing things "properly". This meant usimng Infrastructure-as-code techniques, shipping all changes through an automated release pipeline, and carefully documenting all changes in our agile tool. We decided that these concepts were crucial to the development of a sustainable platform, and were adamant that we shouldn't compromise in these areas.
Kanban reflects reality for Cloud Platform Teams
We had a dynamic mixture of quick fixes, bugs and complex new features in our backlog. When tasks are arriving and being completed in rapid time, it's doubly important to keep track and keep focus on who is doing what. It's also crucial that teams operating at high speed aren't tied up with beurocratic procedures and frustrated by lond winded admin tasks. Ultimately they'll soon start looking for shortcuts, or abandon the helpful parts of work tracking (e.g. linking work items to code check-ins).
Look for the simplest toolset that maps to the reality of your situation. Bending reality to fit a methodology or bug tracking software doesn't sound right - does it?
Simple and Effective
The team used Azure DevOps for work item tracking and planning, and (like most similar tools) it has a Kanban tool. We decided to abandon the concept of Sprints, and manage our workload using just the Kanban tool. This way we could still use our existing toolset, but changed to focus on limitimg work in progress for individual team members, and building team confidence by moving items quickly accross the board into the completed column.